Enabling SDN in Old School Networks with Software-Controlled Routing Protocols

Software-Defined Networking (SDN) promises to significantly improve network manageability by enabling direct, and centralized control over the network forwarding state via a well-defined Application Programming Interface (API). Fulfilling this promise though is a challenge for network operators as it often requires heavy modifications to their current network architecture, including: i) equipment upgrades, as the vast majority of the installed base of network equipments (e.g., routers) do not support SDN protocols; ii) new management, monitoring and provisioning systems; but also iii) the need for operators training as managing and debugging a SDN network requires essentially completely different skill sets. In this short paper, we present a lightweight SDN solution that does not require any new network equipment, nor SDNspecific protocols. While it is less expressive than OpenFlow-based SDN, our solution is powerful enough to fulfill complex traffic engineering requirements (e.g., traffic steering through middleboxes, load-balancing) that are hardly achieved in traditional, configuration-based, networks. Moreover, by minimizing SDN inertial factors and simplifying the management interface exposed to network operators, our lightweight SDN model can provide significant incentives to bootstrap the transition towards SDN [5]. The core of our solution consists of a flexible and vendor-independent API for SDN controllers that works on top of existing networks. Just as OpenFlow enables to program forwarding entries in a SDN switch, our API enables to program forwarding entries in a commercial device such as any Cisco or Juniper router. That API can then be used by a SDN controller such as Floodlight or POX to program the forwarding paths to be used across a traditional network, just as in any other SDN. We argue that routing protocols are good candidates to realize such an API, since they: i) are standardized as routers must interoperate, even if they are from different vendors; ii) have well-defined behaviors (e.g., shortest-path routing); and iii) have been used for years by network operators who now have a good mental model of how they behave. At a high-level, a router running a routing protocol takes routing messages as input and computes forwarding paths as output. A routing protocol can therefore be seen as a function from routing messages to forwarding paths. Such functions are standardized and well-known. Given a forwarding entry to be implemented on a node (i.e., the output) and the set of protocols (i.e., functions) running on that node, the runtime implementing our API automatically computes the routing message (i.e., the input) that, when presented to the node, makes it compute the required entry. Doing so, our runtime inverts the function implemented by the router. In addition to enable SDN functionalities in todays’ networks, controlling routing protocols provides an effective and powerful way to accommodate incremental transitions towards SDN. Indeed, by using our API along with OpenFlow, a SDN controller can program both legacy devices and SDN-enabled equipment. This contrasts with other works on partial SDN deployment (e.g., [2]) that provide SDN functionalities on SDN-enabled devices only. In the following, we provide more details on how our runtime translates forwarding paths into routing protocols messages. Due to space constraints, we focus on one particular application: centralized traffic engineering which is often used as a motivation to deploy SDN [1]. We also focus on one family of intradomain routing protocols: Link-State Interior Gateway Protocols (LS IGPs), as they are used in the vast majority of the networks and are easy to understand since they rely on shortest-path routing. Our approach though generalizes to other routing protocols (including interdomain protocols such as BGP) and forwarding mechanisms (e.g., MPLS). While relying on routing protocols restricts programmability to destination-based forwarding, our runtime is powerful enough to arbitrarily: i) avoid given nodes or links to ensure absence of congestion, ii) steer traffic through middleboxes, iii) load-balance traffic on multiple path for specific destinations, and iv) pre-provision backup paths. We also want to stress that our runtime is more flexible and efficient than simply provisioning static routes. Indeed, by carefully crafting routing messages, our runtime can adapt the forwarding behavior of many devices at once, in a predictable way, without preventing them from converging on their own. In a sense, the runtime only computes the routing input centrally, but the computation of the forwarding paths is still being performed by the routers—in a distributed manner.